1. Technical Field
The present invention relates generally to enterprise data protection.
2. Background of the Related Art
A critical information technology (IT) problem is how to cost-effectively deliver network wide data protection and rapid data recovery. In 2002, for example, companies spent an estimated $50B worldwide managing data backup/restore and an estimated $30B in system downtime costs. The “code red” virus alone cost an estimated $2.8B in downtime, data loss, and recovery. The reason for these staggering costs is simple—traditional schedule based tape and in-storage data protection and recovery approaches can no longer keep pace with rapid data growth, geographically distributed operations, and the real time requirements of 24×7×265 enterprise data centers.
Traditionally, system managers have use tape backup devices to store system data on a periodic basis. For example, the backup device may acquire a “snapshot” of the contents of an entire hard disk at a particular time and then store this for later use, e.g., reintroduction onto the disk (or onto a new disk) should the computer fail. The problems with the snapshot approaches are well known and appreciated. First, critical data can change as the snapshot is taken, which results in incomplete updates (e.g., half a transaction) being captured so that, when reintroduced, the data is not fully consistent. Second, changes in data occurring after a snapshot is taken are always at risk. Third, as storage device size grows, the bandwidth required to repeatedly offload and store the complete snapshot can become impractical. Most importantly, storage based snapshot does not capture fine grain application data and, therefore, it cannot recover fine grain application data objects without reintroducing (i.e. recovering) the entire backup volume to a new application computer server to extract the fine grain data object.
Data recovery on a conventional data protection system is a tedious and time consuming operation. It involves first shutting down a host server, and then selecting a version of the data history. That selected version of the data history must then be copied back to the host server, and then the host server must be re-started. All of these steps are manually driven. After a period of time, the conventional data protection system must then perform a backup on the changed data. As these separate and distinct processes and systems are carried out, there are significant periods of application downtime. Stated another way, with the current state of the art, the processes of initial data upload, scheduled or continuous backup, data resynchronization, and data recovery, are separate and distinct, include many manual steps, and involve different and uncoordinated systems, processes and operations.